おがた (@xtetsuji) です。
最近、他社さんへミーティングに行ったりすることがたびたびあるのですが、議題が終わって場が和んだ時などによく「てつじさん、最近何されているんですか？」と聞かれることがあります。
Twitter などで私の断片的な状況を知っている方も、勉強会で久々にお会いした時に「最近、会社でも二酸化炭素濃度の話ばかりですね」と聞かれたり…。
「謎の人」「風変わりな人」というのはネタとしては美味しいですが、現在の自分に関する情報はなるべく多くの人と共有したいという私の信条もあったりするので、最近あまり書けていないブログを使ってお知らせすることにします。
Twitterでつぶさにお知らせしても、どうしても断片的になってしまうので、「まとめ記事」は定期的に書きたいです。そういう意味では日記回帰もしたいところ。定期的に振り返りを書いておくとある種の周期報（日報、週報、月報…）のような位置付けにもなるし、自分が後で読み返すのにも良かったりするんですよね。
悪い癖で、ザッと書いたらまた長くなってしまった（要約力が無い）ので、個人のタスクはまた別の機会に書こうと思います。
Contents
まえがき
2015年10月に正式ジョインして1年ちょっと経過しました。
所属は「R&D本部（社内では RND と呼ばれます）インフラチーム」。
ガイアックスは事業部制を敷いているのですが、R&D本部は事業部とは独立の組織かつ、各事業部の依頼を横断的に引き受ける部署となっています。このあたりは下記の記事でも公開されています。
2017年2月現在、R&D本部には以下の6つのチームが存在します。
- インフラ
- TSA（世間の会社でいう情シスの上級職→参考）
- TAO（勉強会等のイベント運営や、各事業部に所属するエンジニアの横の連携を強くする）
- PMO（アジャイルなどのプロジェクトマネジメント手法の普及を行う）
- さきがけ（先進的な技術要素で開発を行う）
- セキュリティ室（セキュリティ向上に関わる活動を行う）
この会社、アルファベットの頭字語（acronym）が多いのですが 、私もだいたい正式名称を知らず使っていたりします。世の中もだいたいそんなものですよね（USB とか正式名称を知らない人の方が普通とか）。
その中でインフラチームの主な業務は
- データセンターにあるインフラ（ネットワークおよびオンプレミスサーバ）の運用保守
- オンプレミスサーバの新規構築は昨今のクラウド化の流れで行わなくなりつつある
- クラウド化を推進してオンプレミスサーバの縮退も一つの業務
- クラウドにあるサーバの運用保守、および新規構築の実作業や設計についてのコンサルタント
- 本社オフィス、子会社オフィス、海外拠点など、グループ内の複数拠点にあるオフィスのネットワークインフラの運用保守（オフィス移転時にはネットワーク等の新規構築も行う）
- セキュリティ脆弱性への対応
といったもの（パッと思い出したものを列挙）。様々な部署がサービス提供に利用している歴史的なオンプレサーバを数百台抱え（チームの人数で割ると一人あたり100台弱です）、それらを徐々にクラウド化しつつ、新規の依頼は最初からクラウドによってサーバを構築している、というのが現状です。
その中での私はというと、最初の1年は指示されたお仕事を一つ一つこなしながら、システムや関連部署などの構成要素を勉強しつつ自分なりの仕事をしていく時期でした。
上記スタンス、パッと聞くと受身と思われるかもしれません。ただインフラチームという仕事柄、相当広範なアクセス権限をもらうことになるわけで、ジョイン直後の何もわからない時期に「破壊的イノベーション」を振りかざさないよう結構気をつけていました。組織の事がわからないと、成果を出そうとちょっと勇み足になっただけで、他者から見たら「最近入ってきた奴が広範なアクセス権限を使って危ない事をしようとしている」となりがちです。それと、いくらIT業界がドッグイヤーだからといって、2015年に一度「東京」と「IT」から本気で離れようと思った自分にそんなに成果を急ぐ考えもありませんでした。
このブログでも何度か書いていますが、もともとの私は約10年間Perlプログラマとしてウェブアプリケーション開発を担当していました。学生時代は流行り始めの Linux で自宅サーバを構築したりとインフラ志向だったこともあり、Linux サーバの扱いだったりといったことは得意ですが、アプライアンスのネットワーク機器などはほとんど経験がありません。学校を卒業して1社目に入社する時はインフラ志望で、プログラマになろうとなんて全く思っていなかった（そもそもろくにプログラミングできるスキルは無かった）のですが、当時のインフラの責任者が相当厳しい人で、そのためかスキルが低い（と見なされた）私をインフラ所属にしてくれなかったことで Perl プログラマとして数奇な人生を歩むことになったのは、結果的に良かったなと思っています。
2015年に10年ぶりにインフラという職種についたものの、ネットワーク機器が苦手ということは変わらないのですが、興味のあるところでもあるので余裕を作って勉強していきたいです。とはいえ、今まで対応できる人がおらずに放置されていた仕事の中で自分が持っているスキルが使えるものがいくつかあり、直近もそこの業務に力を注ぐことになって意外と余裕が無かったりします（数年前までの激務時代に比べたら暇みたいなものですが）。
特に、軽微な不具合が有りつつも対応できる人がおらず使われ続けていたメールサーバ群の各種対応も行ったりしている（後述）のが代表的でしょうか。メールサービスASPを提供していた会社で約10年システム開発業務に携わっていた私のスキルが今も活かせるのは興味深いです。メール技術はウェブ業界で邪険な扱いを受けることも多いですが、今体験できる課題には全力で取り組んでおくべきだと改めて感じます。
私の業務では、保守しているサーバで関連がある各部署や各拠点との関連の他、R&D本部内では TSA、TAO、そしてセキュリティ室と連携する機会が多いです。TSAとは情シス系業務を越えたサーバオペレーション等について、TAOとは私が個人的にコミュニティ活動やOSS活動をしている知見の提供、そしてセキュリティ室とはミドルウェアのセキュリティ脆弱性のサーバ上での対応などで密接です。
給与面談での評価等のため、業務は大きく「施策」「通常業務」に分かれています。通常業務の方は、通年に渡って発生するルーチンワークであったり、ハードウェア故障の対応や、他部署からの差し込み依頼などが入ります。施策の方は、現状の大きな改善のために上司と相談しつつ四半期を単位として設定する大きな業務目標のことです。
以下、サブセクションで区切りながら、公開して差し支えない範囲で現在抱えている業務を書いていきます。
メールサーバの縮退
上述のメールサーバとメールシステムについてのお仕事です。メールサーバ縮退に関するものは施策として進めています。
Postfix がよく出てくるので、個人的に「P系」と呼んでいます。
社員が持つメールアドレス周辺は、私が入社する前に外部ASPに載せ替え済み（そして現在の管理はTSA）なのですが、一部のメーリングリストだったりサービスで使っているドメインでメールを受信する必要がある場合に使われているメールサーバ群が数台あります。
しかし、これらサーバを構築した人達が退職した後は保守があまりできていない状況となっていました（よくある話ですね）。この部分を見直しつつ、不要なドメイン設定の削除や、ASP等へのメール機能の追い出し等を行って、メールサーバ群を縮退していくお仕事です。
このメールサーバ群は Postfix をはじめとした各種OSSの組み合わせとともに、自社開発の管理ツールがセットになっているシステムです。ただ、選定されたOSSのうちの一部が古くなり、また自社開発の管理ツールのコードの保守も難しいというのが課題となっています。
一部のOSSが古い問題にはいくつか策を講じているものの、抜本的解決のためにはシステム全体を作り直すか、システム自体無くしてしまって問題ない状態にするしかなさそうです。ならば管理ドメインを減らしながら全体を縮退しつつ、残ったものを外部ASPに載せ替えるためのとても軽量なシステムを書く方向で作戦を立てています。
個人的には新たなメールシステムを一から作ることに相当な興味がわくのでが、多くの側面から現実的ではないでしょう。業務戦略的には見合わないこと、今後もメールシステムに詳しい人は減り続けて保守運用の引き継ぎもままならないこと、外部ASPを組み合わせて新しいシステムを作ることも興味深くチームでの保守の観点からも好まれること等が理由です。
そこそこの規模のメールシステムとの遭遇は個人的に良い出会いでもあり、この施策は意欲的に取り組んでいます。また、ここで得られたメールシステムに関する知見や成果はなるべく公開して、今もまだいるだろうメールシステムに携わる人の助けとなるようにしていきたいです。
共用ウェブサーバの縮退
上述のメールサーバの縮退に関連して、多くのバーチャルホストが乗ったウェブサーバの対応も通常業務の一環で進めています。
そもそも多くのサービスのバーチャルホストを載せたサーバは関係する部署や顧客も多く、セキュリティ対策のためにサーバを一瞬止めるだけで一苦労です（作業自体というより事前交渉が）。また、載せているコンテンツ類も様々で、セキュリティ脆弱性の把握や対処も難しくなっています。
こちらについても不要なコンテンツの掃除を進めつつ、クラウド化しつつ見通しの良い配置にしていくことを進めています。
メールサーバや共用ウェブサーバの実体はデータセンターで稼働しているオンプレサーバです。これらをクラウド化することで、ハードウェア故障といった煩わしい対応からも解放されたいと考えています。
インフラチームでは、人数比での台数割合も多く老朽化も進んでいるオンプレサーバ全体の縮退とクラウド化も推進しており、P系を含めた私の活動もその一環となっています。
各種社内ツールの統合・縮退・廃止
多くなりすぎた社内ツールを何とかする仕事です。
目下のタスクとして、Wiki 目的で過去のプロジェクトのたびに作られたと思われる Trac が数百あり、その廃止のため作業をしています。私の施策の中では「Trac縮退」という名前となっており、その名前から私は「T系」と呼んでいます。もともとは、歴史ある Trac や Redmine 、そして最近導入された Qiita:Team や Google Document など、社内に文書を書く場所がいくつも存在しており、必要な資料がどこにあるのか入社後しばらく全く分からなかった私の経験に基づいた施策でもあります。
「会社の10年生存率は10%」とはよく言われたことですが、10年生存したIT企業だと様々な社内ツールがひしめき合っていることは特に珍しいことではないでしょう。優秀な人達によって支えられた会社だと、問題解決のために社内ツールを即興で自作したり、アーリーアダプタ的センスを持った人によって新規ツールが導入されることは日常茶飯事ですが、ガイアックスもこれに該当する企業と言えましょう。
社内ツールが増えるその他の要因としては、新卒新入社員にエンジニア講習の一環で社内ツールを作ってもらうケースや、若年層の腕試しや新規技術の検討のため（商用投入前に）社内ツール開発という機会を利用するというというケースがあります。
「思い立ったらすぐツール開発ができる」環境やスキルは素晴らしいです。ただ、以下の問題点は無視できません。
- 開発後の保守が継続されない問題
- 同様のツールが乱立する問題
- 使われている内部技術がバラバラで保守が大変な問題（特に腕試しや新規技術で開発された場合）
保守継続問題ですが、以下のような理由により意外と難しいと実感します。
- 開発した人は開発完了後に別の開発案件で多忙になって時間が取れなくなる
- 開発した人が退職した場合
- 社内ツールという性質上、商用開発物以上にドキュメントが無い場合が多く、引き継ぎや後任担当者のシステム理解の難易度が高い
- 新規技術の検討で作られた社内ツールの場合、投入した技術が結局流行らず廃れたものだと保守に様々な負担が発生する
このようなケース、皮肉なことに優秀な人ほど陥りやすい気がします。
同様のツールが乱立する問題は、やはりアーリーアダプタが多いIT企業ならではと言えましょう。新しいツールを取り入れていくことは業務改善やモチベーションアップのために必須なことですが、導入だけに注力して既存ツールからの移行と既存ツールの縮退ロードマップが描けないと、中長期的にこのような問題に陥ってしまうような気がします。T系の施策のメインテーマです。
私が引き受けているツールに関しては、内部技術がバラバラ問題はそこまで深刻ではないのが幸いです。プログラミング言語はほぼ Ruby と Perl のどちらかなので、プログラミング言語と LAMP の基礎のレイヤーでの悩みは少ないですが、デプロイ方法であるとか、デーモン構成であるとかといった部分に揺らぎがあり、時々頭を悩ませます。ここにこそドキュメントが欲しい部分ではあるのですが、意外と無いケースが多いです。
デプロイ方法のドキュメントの代わりのようにリポジトリに残された Ansible Playbook の中を読むと、今の環境だとこれはうまくいかないといったケースがあったりと、（追加開発はしないまでも）保守だけ行う場合でも、前提知識が少ない人にとって若干の難易度の高さを感じます。
文書の要不要の話をするときに私がよく言うのは、文書は「手順」を書くだけでなく、当時の「要求」や「事情」も盛り込んでおくべきというものです。その意味では、文書もコメントもないプログラムやデプロイスクリプトは「手順」だけでしかなく、それが今通用しないとなると、コードの行間から「要求」や「事情」を読み取るコストは意外に高いです。
ここまで特に悲観的ということもなく、優秀なエンジニアに長年支えられてきたある程度以上の規模のIT企業が一度は経験する普通の状況だと思います。新規開発は技術力が試されますが、既存ツールの廃止は使い続ける保守的な社員との交渉といった政治力が試されがちで、優秀なエンジニアがそこにコストを払うのはもったいなくもあります。
会社のフェーズとして今は新規開発が無いという時も、若年エンジニアには新規開発の腕試しをさせてあげたいと考えるのは私も同じで、そういう時に社内ツールというのは良い題材ですし、今後もそういう出自の社内ツールは応援したいです。もし応援するのであれば、ついでに最初からオープンソースにするロードマップを描こうと思います。
目下の私は、社内にある数百の Trac を縮退しつつ、保守担当者がいない社内ツール群を引き取って他のチームと協力しながら保守しやすい形にしていくことが目標です。さながら社内 Apache Foundation といったところですが、運用保守と現状に合わせた改善は、真っ向から読み解く必要がある既存ツールから知らないことを学べたり、新規開発とはまた違う面白さがあると思っています。
既存のオープンなツールではあまり聞かない独自の機能を提供する優秀な社内ツールも結構あり（これは世間に無いから作ったという好ましい動機です）、保守しやすい形にするめどが立ったところでいくつかのツールを OSS 化していく事も検討しています。
各種セキュリティ対応
インフラチームでは、各種ミドルウェアの脆弱性が公開されて修正パッケージがリリースされた時に対応をしたりといったセキュリティ対応を行っています。
全てが統一されたサーバであれば楽なのですが、載っているアプリケーションもOSもミドルウェアも完全には統一されておらず、意外な負担があるタスクです。実際に現在どのように使われているか把握しながら主担当者と調整しつつ、メンテナンス時間などを調整して作業を行ったりします。
歴史あるオンプレサーバ特有の「古いOS問題」も可能な限り対応をしつつ、コストを比較した上でクラウド上の最新OSへ載せ替えたりといった作業も並行して行っていきます。AWS に移行してその機能を最大限に活用すれば、OpenSSL や BIND といった脆弱性の風物詩とも疎遠になるのは魅力的です。
昨今は CMS のセキュリティ対策についても課題です。社内では部署によって過去いくつかの CMS を使っており、今も残るその対応なども時々課題となります。
各論ある部分ですが、PHP の CMS の戦国時代は WordPress によって統一されたと私個人としては考えており、ソフトウェア保守や世間のノウハウが少なくなってきている古い CMS を廃止して、多くの人が使っている WordPress 寄せを進めることには多くのメリットがあると思います。
余談ですが、WordPress は動作が重かったりといったネガティブな意見も見かけます。ただ、それは人気がある裏返しでもあるでしょう。多くの人に支持されているだけのメリットは大きいと感じますし、それゆえ WordPress のスキルはポータブルスキル（違う職場でも通用するスキル）であったり、そのノウハウ自体が自社や自部署の魅力的な商品にもなります。
生粋の Perl プログラマである私には「Perl なら MovableType では（略）」「MovableType なら静的生成なので動作コストや」といった意見もよく寄せられまして、その魅力にいつも納得しています。ただ、MovableType の世界に首を突っ込むと「テンプレートが PHP（Apache で AddHandler php-script .html されている）」という状況になりがちで、「結局 PHP 書くなら…」と WordPress 側に流されてしまう私です。この個人ブログも WordPress です。
むしろ、MovableType で動的コンテンツを作るのであれば、Apache (HTTPD Server) で mod_perl と event_MPM をフル活用して、出力ドキュメントの部分ごとに決定論的なキャッシュが可能だったり、Perl で出力コンテンツの一部をテンプレート文法的に書くことができたりといった効率的な仕組みを書いてみたいなぁと思ったりしています。同様の機能を Plack Middleware 等でも書いておけば Apache 嫌いな人にも安心（？）ですよね。
TSAチームへの引き継ぎのための業務効率化
インフラチームはサーバ関連の運用保守に集中できるよう、ルーチンワークに落とし込めるものは属人化を排除して各種ドキュメントやツールを整備した上でTSAチームに引き継ぎをするようにしています。
直近の私は、SSL証明書のサーバ上での更新作業をTSAチームへ引き継ぐための仕事の一部を行っています。
全社的・事業部広域に渡るSSL証明書を管理するツールは存在しますが、更新作業はインフラチームが主に行っていました。ただ、当作業はそこそこルーチンワークになっており、引き継ぎと属人化を排除する機会となっています。
各種イベント運営
プライベートでも勉強会運営などに携わっている経験を買われて、昨年末あたりから自社のエンジニアのPRを目的としたイベント運営にも携わっています。こちらはイベント運営チームの中の一人として動いています。
Connpass に自社エンジニアグループを作成して、その中で2回イベントを行いました。社内ツールの運用保守を引き受けることが多くなった私の「他社の社内ツールを見てみたい」といった要望が #社内ツール大公開 というイベントになり、「面白いデスクを見てみたい」といった要望が #こだわりデスク というイベントになりました。#こだわりデスク の方では私も発表させていただき、ほどほどにウケてホッとしました（スライド）。
IT企業が普通にテックカンファレンスをやる時代ですが、既にテックカンファレンスが多くなってレッドオーシャンっぽくなってきたことや、私自身がそれほど高度な知識がないこともあって、ひとまず最初のうちは緩く楽しめるイベントに興味が向いています。
イベント運営チーム発案のイベントだけでなく、社内エンジニアから持ち込まれたイベントの運営もお手伝いしていく予定です。直近ではTSAチーム企画による「情シス女子」というイベントの運営をお手伝いします。
最近はブランディングに力を入れている自社ですが、全社的なイベントについてはブランディングに関わる専門チームが存在しており、直接の関わりはありません（ウェブサーバの準備といった依頼ではインフラチームとして関わりがある場合もあります）。また、部署や事業部の独立性が高いこともあり、私が所属しているチームが関与していないエンジニア系イベントも多くあると思います。
あとがき
ざっとみると、「縮退」「廃止」「統合」といった言葉が目立つように、モノを作る仕事よりもモノを減らす仕事が多いというのが特徴です。実際、業務でコードはそれほど書いていません。最初の方で「破壊的イノベーションを振りかざさない」と書いておきつつ、言い方を変えれば破壊に近いのかも。
私は2015年に10年ぶりの引っ越しをしたのですが、何ヶ月引っ越し作業をしても減らない物の山に、物を減らしてシンプル化することの重要性を痛感しました。もともと私は片付けが苦手な人間なのでまだまだ精進ではありますが、業務にもそういう最近の考えが現れているのかもしれません。世間の言葉で言えば「断捨離」といった感じでしょうか。
さまざまな業務がある中で、どちらかというと私の得意分野を評価してもらって任されている仕事が結構あり、やりがいもあって期待に応えたいという思いです。それと同時に、本来は着手すべきであるものの、前述のような仕事に押され、着手のモチベーションもそこまで高くないという仕事が後回しになる場面もあり、反省半分といった気持ちです。
今後は時間やリソースの配分を工夫して、得意分野で成果を上げつつ、着手に心理的障壁がある類の仕事も進む仕組み作りをして新たな勉強をしていきたいです。